I did a modification of the export to HTML to handle an "inlineTable" Basically a DOORS object that has an additional attribute that if set "True" will convert the Object's Text (from Tab seperated data) to an HTML formatted table. Has been working well and good for about a year. All of sudden it looks like it hangs. Lots of investigation finding it is not hanging, just taking almost forever to process some objects.
In the process I put in debug statements to output the debug to a file. My latest discover relates to how slow the processing gets and how it keeps getting slower.
For each row of the table, I output how long it took to process (only have a resolution of 1 second). It processed the first 150 rows in about 1 second. It then processed the next 20 rows in another second, then it took another second to process another 10 rows, keeps gettting slower and slower per row. Abotut row 700 it is now taking about 6 seconds per row! All the while I am watching DOORS memory usage grow and grow. It started about 250K bytes, currently approaching 1,293K and still growing.
All the program is doing when it processes the "row" is it appends HTML tags, (ie <td> data found </tr> to a DXL buffer. From data gathered the "expansion" from input characters to output buffers is about 4x, so I would expect the final result of the buffer created to be 800K).
Currently I use something like myB = myB (new stuff to add) I am going to see if myB += (new stuff to add) does any better.
TIA
F-Skier - Fri May 05 13:16:05 EDT 2017 |
Re: Exponential increasing processing time There is no problem with buffers on DOORS. They can easily handle 100s of MB of data without getting inefficient. They resize though, but still this should not matter very much.
There are two problems for slowdown in DOORS: - massive string table leaks Another very common problem is continuous opening and closing of modules. Especially if you are working with links and export data from linked modules unoptimized code needs to constantly open/close modules to avoid memory exhaustion due to too many open modules. The builtin export is probably very very inefficient. Unfortunately it is not easy to find and get rid of memory/string table problems inside a program. The first thing you should do, is try to verify that this is really a leak/string table problem or maybe an open/close modules problem. I dont know how experienced you are with DXL? There is a lot of information on the forum on how to debug and resolve these kinds of problems. Maybe that helps, regards Mathias |